Method and system for merchant processing of purchase card transactions with expanded card type acceptance

ABSTRACT

Systems and methods for merchant processing of purchase card transactions with expanded card type acceptance are provided. For each merchant, a record is maintained of each card type that the merchant accepts, and merchant-specific transaction processing parameters are associated with each card type. During transaction processing, a card type for the transaction is identified from transaction data submitted by the merchant, and the merchant-specific transaction processing parameters associated with the identified card type are used to control transaction processing.

BACKGROUND OF THE INVENTION

The invention relates generally to merchant processing of purchase cardtransactions. In particular, the invention relates to systems andmethods for processing a variety of purchase card products andtransaction types that may be presented to a merchant.

Purchasing of goods and services using a purchase card (e.g., creditcard or debit card) for payment has become commonplace. Card issuers,such as banks, retailers, or other financial service providers, providecardholders with purchase card accounts. The card issuer agrees totransfer funds to various merchants—either directly or via anintermediary—in payment for goods and services received by thecardholder, and the cardholder agrees either to repay the card issuer orto have funds deducted from the cardholder's deposit account. Thecardholder receives a presentation instrument, which is typically arectangular piece of plastic bearing a card number and other identifyinginformation. To purchase goods or services, the cardholder eitherpresents the presentation instrument or provides the card number to amerchant. The merchant accepts the presentation instrument and deliversthe goods or services to the customer, generating a transaction record(ticket) in paper or electronic form. In order for the merchant to bepaid and the cardholder to be billed, the merchant typically submits theticket to an acquiring bank for processing.

Acquirer processing (also called merchant processing) of purchase cardtransactions is complicated by a number of factors. For instance, how apurchase card transaction is processed depends on the particular cardproduct used. For example, some card products (e.g., VISA and MASTERCARDproducts) are “interchange” cards, which are issued by various banks orother institutions under the authority of a card association thatestablishes rules regarding the use and acceptance of the card products.Each card association typically provides an interchange service forrouting transactions between an acquiring bank and a card issuing bank.An interchange card generally may be accepted by any merchant, as longas the merchant maintains an account with an acquiring bank (or otherinstitution) that participates in the card association. Authorizationand settlement requests for interchange cards are generally processed byrouting the requests from the acquiring bank to the card association,which then routes the requests to the card issuing bank. Other cardproducts may be “private label” products, for which routing of requestsbetween banks is not supported. For such cards, it is generallynecessary the acquiring bank also be the card issuing bank, making theacceptance of such cards limited. Examples include credit cards issuedby retailers, which are usually accepted only at the retailer's ownoutlets.

Transaction processing is further complicated by the variety of cardproducts that a single card association or issuer may offer. Forinstance, a large card association (e.g., the VISA or MASTERCARDassociation) typically offers a range of card products such as creditcards (where the cardholder is billed for purchases), check cards (wherepurchase amounts are deducted directly from the cardholder's checkingaccount), corporate cards (where an employer of the cardholder receivesthe bill), and so on. Each card product may be subject to differentrules and regulations regarding the use, acceptance, and processing ofthe card product.

Still more complexity arises due to card issuers' participation inelectronic debit networks such as the NYCE or PLUS networks. These debitnetworks typically do not issue card products themselves. Instead, theyagree with various banks to provide network services for routing debitcard transactions from an acquiring bank to a card issuing bank. Anissuing bank may participate in multiple electronic debit networks;cards issued by the bank generally bear a badge for each debit networkin which the bank participates. Thus, depending on where and how it ispresented, the same plastic could be used, e.g., for a credit cardtransaction to be routed through the VISA interchange or a debit cardtransaction to be routed through the NYCE network or the PLUS network.An acquiring bank must be able to distinguish these uses and properlyroute each transaction.

Yet another layer of complexity is added by the possibility that thecardholder may present the same card to a merchant for different typesof transactions. For instance, in addition to sales transactions, thecardholder may desire to return goods previously purchased using thecard, obtain a cash advance using the card, or make a payment on theoutstanding balance of the card account. Each card association or issuerhas rules related to whether a merchant may accept a particular cardproduct for each type of transaction. For instance, a retail outlet maybe authorized to accept an interchange card for sales but not for cashadvances; the same retail outlet may be authorized to accept both salesand cash transactions using a debit network.

To accommodate customer preferences, many merchants desire to offer avariety of options to their customers, including the ability to use anumber of different card products from different issuers, associations,and networks, as well as the ability to perform different types oftransactions for a particular card product. At the same time, merchantsalso desire to control expenses associated with accepting different cardproducts, for instance, by not having to maintain accounts with a numberof different acquiring banks. Thus, in order to provide effective cardprocessing services to a merchant, an acquiring bank must be prepared toprocess a variety of card products and transaction types, routing eachtransaction to the correct destination, deducting appropriate fees, andkeeping accurate records of activity.

To assist acquiring banks, third-party merchant services providers offertransaction processing services to a number of such banks. In additionto managing the processing and recording of card transactions, such athird-party provider must also manage information regarding which cardproducts and transaction types a particular one of its acquiring bankclients is allowed to accept, in addition to information about eachmerchant.

An acquiring bank or a third-party service provider generally operatesone or more platforms for processing purchase card transactions. Eachplatform includes various data stores, such as merchant records thatprovide information about each merchant account; the record for aparticular merchant may be identified by a unique merchantidentification number. The platform receives a batch of transactiontickets from the merchant, transfers corresponding finds to themerchant's account, routes tickets to the appropriate entities forsettlement, and keeps records of the merchant's activity for accountingand reporting purposes.

Existing systems are limited in their ability to process a merchant'stransactions involving a variety of card products and transaction types.For example, in some existing systems, a private label card isimplemented using a processing platform that has both the cardholderaccount records and the merchant account records, thereby eliminatingthe need to route the transactions to another system for settlement.However, such platforms may be unable to handle processing ofinterchange card transactions, for which different formatting androuting procedures are required. Thus, a separate platform is usuallyprovided for interchange cards. Consequently, a merchant who acceptsboth a private label card and an interchange card must have a record ontwo different platforms, generally with a different identificationnumber on each platform. Either the merchant must submit transactionsseparately (i.e., in separate batches) for the two card products or thetransactions must be rebatched prior to processing. In either case,there is generally no link between the merchant records on the twoprocessing platforms: the merchant receives reports separately for eachcard, and any changes to the merchant data (e.g., the merchant'saddress) must be made separately on each system. Similar problems mayarise in regard to other combinations of card products havingconflicting processing rules. In some instances, the overhead associatedwith handling additional card products causes acquiring banks orthird-party providers to limit the merchant's options for acceptingvarious cards.

Existing systems also limit the ability of a merchant to acceptdifferent transaction types. For instance, many existing systems limit amerchant record to one or two transaction types per card product (e.g.,sales and returns only, or cash advances and payments only). Thus, if amerchant desires to accept both sales and cash advance transactions fora particular card product, two records would have to be maintained forthe merchant. Either the merchant is required to submit separate batchesfor each transaction type or the transactions are rebatched prior toprocessing. Again, this leads to inefficiency and overhead that maycause acquiring banks or third party providers to limit the merchant'soptions for allowing customers to perform different transactions.

Further, existing systems also limit the acquiring bank's ability toassess fees that reflect the bank's actual costs. For example, when anacquiring bank acquires a ticket, it generally pays to the merchantaccount an amount less than the face value of the ticket by a percentageknown as the discount rate. The discount rate reflects the risk that theacquiring bank will not be repaid by the card issuer; in the case ofinterchange cards, it also reflects the interchange fee (set by the cardassociation) that the acquiring bank will have to pay in settlement ofthe transaction. The risk and the interchange fee may vary depending onthe card product used. For instance, a card association may set aninterchange fee of 2% of the transaction total for transactions usingits credit card products and 3% of the transaction total fortransactions using its debit card products. Such fees may vary from oneassociation, issuer, or network to another. However, existing systemstypically do not enable the acquiring bank to determine the discountrate on a transaction-by-transaction basis. In some systems, themerchant record is associated with one discount rate so that applyingdifferent discount rates for different transactions would again requiremaintaining multiple records for the same merchant. Further, existingsystems for processing ticket acquisition often do not supportdetermining the particular card product that was used.

Hence, it would be desirable to manage merchant accounts in a mannerthat provides increased flexibility for acquiring banks to processdifferent card products and different transaction types, and to pricetransactions according to the card product used.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention provide systems and methods formerchant processing of purchase card transactions with expanded cardtype acceptance, enabling processing of merchant transactions involvinga number of card products for various transaction types without the needto maintain multiple records for a merchant. For each merchant, a recordis maintained of each card type, and transaction processing parametersare associated with each card type. A “card type” may be defined tocorrespond to a single card product, a group of card products, or onlycertain cards of a particular card product. During transactionprocessing, a card type for the transaction is identified fromtransaction data submitted by the merchant, and the transactionprocessing parameters associated with the identified card type are usedto control transaction processing. Because the processing parameters canbe specific to a particular merchant and a particular card type, asingle platform can support any merchant accepting any card type orcombination of card types, including interchange cards and private labelcards issued by the merchant or by other merchants. In addition, thesame card can be subjected to different processing rules depending onwhere it is presented.

According to one aspect of the invention, a method for processing apurchase card transaction submitted by a merchant is provided. Apurchase card identifier is extracted from transaction data submitted bythe merchant. A card type corresponding to the purchase card identifieris identified from a list of card types accepted by the merchant, thelist of card types corresponding to a plurality of card productsincluding an interchange card and a private-label card. The purchasecard transaction is processed according to merchant-specific rulesdetermined from merchant-specific processing parameters associated withthe identified card type. The merchant-specific processing parametersmay be used to determine, e.g., whether the merchant is allowed tosubmit transactions of the submitted type, where to route thetransaction data for settlement, how to format the transaction data,whether the acquirer reimburses the merchant, what discount rate toapply, and so on. The list of card types accepted by the merchant mayinclude at least one private label card issued for a retailer, where themerchant is not an outlet of the retailer.

According to another aspect of the invention, a method of processingpurchase card transactions is provided. A plurality of card types isdefined, at least one of the plurality of card types corresponding to apurchase card and having associated therewith a plurality ofmerchant-specific sets of transaction processing parameters. Each of aplurality of merchants is authorized to accept one or more of theplurality of card types. Upon a cardholder presenting to a merchant thepurchase card corresponding to the at least one card type havingassociated therewith the plurality of merchant-specific sets oftransaction processing parameters for a transaction, the transaction isprocessed using one of the plurality of merchant-specific sets oftransaction processing parameters that corresponds to the merchant. Afirst one of the plurality of merchant-specific sets of transactionprocessing parameters may include a first routing destination parameter,and a second one of the merchant-specific sets of transaction processingparameters may include a second routing destination parameter differentfrom the first routing destination parameter. The purchase card may beara first badge identifying a first card issuing entity and a second badgeidentifying a second card issuing entity. In this case, the firstrouting destination parameter can correspond to a routing destinationfor a card product of the first card issuing entity while the secondrouting destination parameter corresponds to a routing destination for acard product of the second card issuing entity.

According to another aspect of the invention, a method for processingpurchase card transactions submitted by a plurality of merchants isprovided. A plurality of card types is defined, each card typecorresponding to a group of purchase cards and having associatedtherewith a set of merchant-independent transaction processingparameters. For each of the plurality of merchants, a merchant card typelist is created. Each merchant card type list includes a subset of theplurality of card types, and a set of merchant-specific transactionprocessing parameters is associated with each card type in the subset.For each purchase card transaction, a card type corresponding to thepurchase card used in the purchase card transaction is identified fromthe merchant card type list for the merchant submitting the purchasecard transaction. The merchant-specific transaction processingparameters and the merchant-independent transaction processingparameters associated with the identified card type are used to controlprocessing of the purchase card transaction. The plurality of card typesmay include a private label card type corresponding to a private labelcard of an issuing retailer, and a first merchant card type list for afirst merchant that is not an outlet of the issuing retailer can includethis private label card type. A second merchant card type list for asecond merchant that is an outlet of the issuing retailer can alsoinclude this private label card type. Merchant card type lists may becreated from default card type lists, and additional card types can beadded to the default card types on a merchant-by-merchant basis.

According to another aspect of the invention, a method for processingpurchase card transactions submitted by a plurality of merchants, eachof which is associated with one of a plurality of acquirers, isprovided. A master card product list is defined to include a pluralityof card types, each card type corresponding to a group of purchase cardsand having associated therewith a set of merchant-independenttransaction processing parameter values for the group of purchase cards.For each acquirer, an acquirer-level card product list is defined, eachacquirer-level card product list including a subset of the plurality ofcard types. Each merchant is associated with at least one of the cardtypes included in the acquirer-level card product list of the associatedacquirer, and for each card type associated with the merchant, valuesare established for a set of merchant-specific transaction processingparameters. For each purchase card transaction submitted by one of theplurality of merchants, a card type for the purchase card used in thepurchase card transaction is identified from the at least one card typeassociated with the merchant. The merchant-specific transactionprocessing parameter values and the merchant-independent transactionprocessing parameter values associated with the identified card type arethen used to control processing of the purchase card transaction.

According to another aspect of the invention, a system for processing apurchase card transaction submitted by a merchant is provided. Thesystem includes: an interface configured to receive transaction data forthe purchase card transaction; control logic configured to identify acard type for the purchase card transaction from a list of card typesaccepted by the merchant using the received transaction data, the listof card types corresponding to a plurality of card products including aninterchange card and a private label card; and control logic configuredto process the purchase card transaction according to one or moremerchant-specific rules associated with the identified card type.

According to another aspect of the invention, a system for processingpurchase card transactions for a plurality of merchants is provided. Thesystem includes: an interface configured to receive transaction data tobe processed; a server configured to perform a transaction processingoperation using the transaction data; a card product data storecontaining a master card product list, the master card product listdefining a plurality of card types and associated merchant-independentprocessing parameters; and a merchant master data store containing amerchant card type list for each of the plurality of merchants, eachmerchant card type list including at least one of the plurality of cardtypes and associated merchant-specific processing parameters. The serveris further configured to use a merchant card type list for a merchant toidentify a card type for a purchase card transaction submitted by themerchant and to use the merchant-independent and merchant-specificprocessing parameters associated with the identified card type tocontrol the transaction processing operation.

According to another aspect of the present invention, a system forprocessing purchase card transactions submitted by a plurality ofmerchants, wherein each of the merchants is associated with one of aplurality of acquirers is provided. The system includes a data storehaving: (1) a master card product list including a plurality of cardtypes, each card type corresponding to a group of purchase cards andhaving associated therewith one or more merchant-independent transactionprocessing parameters; (2) a plurality of acquirer-level card productlists, each acquirer-level card product list including a respectivesubset of the plurality of card types; and (3) a plurality of merchantcard product lists corresponding to the plurality of merchants, eachmerchant card product list including at least one of the card typesincluded in the acquirer-level card product list of the associatedacquirer, each card type in each merchant card product list furtherhaving associated therewith one or more merchant-specific transactionprocessing parameters. The system also includes control logic configuredto identify a card type for a purchase card used in a purchase cardtransaction submitted by a merchant, the card type being identified froma merchant card product list corresponding to the merchant submittingthe purchase card transaction; and control logic configured to processthe purchase card transaction using the one or more merchant-independenttransaction processing parameters and the one or more merchant-specifictransaction processing parameters associated with the identified cardtype.

The following detailed description together with the accompanyingdrawings will provide a better understanding of the nature andadvantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a merchant processing platformaccording to an embodiment of the present invention;

FIG. 2 is a table representing contents of a master card product listaccording to an embodiment of the present invention;

FIG. 3 is a simplified block diagram of a merchant master databaserecord according to an embodiment of the present invention;

FIG. 4 is a table representing contents of a merchant card type listaccording to an embodiment of the present invention;

FIG. 5A-B are, respectively, a simplified block diagram of ahierarchical arrangement for merchant records and a structure diagramfor a numerical representation of the hierarchical location of amerchant, according to an embodiment of the present invention;

FIG. 6 is a flow chart of a process for building a merchant card typelist according to an embodiment of the present invention;

FIG. 7 is a simplified block diagram of relationships of various cardtype lists according to an embodiment of the present invention;

FIG. 8 is a flow chart of authorization request processing according toan embodiment of the present invention;

FIG. 9 is a flow chart of processing a debit-network transactionaccording to an embodiment of the present invention;

FIG. 10 is a flow chart of acquisition processing for a batch of ticketsaccording to an embodiment of the present invention; and

FIG. 11 is a flow chart of accounting processing steps according to anembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention provide improved systems andmethods for merchant processing that enable merchants to accept avariety of card products for various transaction types. According to oneembodiment of the present invention, a transaction processor (e.g., anacquiring bank or a third-party provider of merchant processingservices) maintains a record that identifies each card type and theassociated transaction types that a particular merchant is authorized toaccept. As will be apparent from the present disclosure, a “card type”may correspond to a single card product, a group of card products, oronly certain cards of a particular card product. A process forauthorizing a transaction includes determining whether the merchant isauthorized to accept the card product presented for the transaction typeselected. During ticket acquisition and settlement, an identifier of thecard type is used to control the acquirer-side processing of the ticket.

FIG. 1 is a simplified block diagram of a merchant processing platform100 according to one embodiment of the present invention. Merchantprocessing platform 100 operates to provide merchant processing servicesfor one or more acquirers, which may be banks or other financialservices institutions. In one exemplary embodiment, merchant processingplatform 100 is under the control of an acquirer; in another exemplaryembodiment, merchant processing platform 100 is under the control of athird-party provider and is used to provide merchant processing servicesfor one or more acquirers that are clients of the third-party provider.

Merchant processing platform 100 includes a server 105, which mayinclude a single computer or any number of networked computers. Ingeneral, server 105 manages updating of merchant information, processingof individual transactions, and reporting of merchant account activity,as will be described further below. Various operations of server 105 maybe automated; for instance, settlement of a batch of tickets may beautomatically initiated on a daily basis. It will be appreciated bypersons of ordinary skill in the art that where server 105 isimplemented using multiple computers, the various functions of server105 may be assigned to various ones of the computers in any suitablemanner.

Server 105 accesses various data stores including a merchant master datastore 110, a ticket data store 115, and a card product data store 117.Merchant master data store 110 provides storage of merchant-specificinformation needed to process transactions for a particular merchant,including information regarding the card types accepted by the merchant,as will be described further below. Ticket data store 115 containsinformation regarding individual purchase card transactions (including,e.g., authorization and ticket transactions) for use during processing.Card product data store 117 provides storage of information related tocard products for which transactions may be processed using platform100. Each data store may include any suitable data structures, such asdatabases and/or data files (e.g., Virtual Storage Access Method(“VSAM”) files). The data structures may be stored on any suitablecomputer-readable storage media, including optical or magnetic storagemedia. In addition, the data stores may be on separate storage devicesor the same storage device.

In the embodiment shown, server 105 also accesses a program library 120that houses executable instructions for performing various merchantprocessing functions. Server 105 may be configured to execute variousprograms from library 120 automatically (e.g., on a periodic basis) orin response to user commands received via a user interface 125. Inembodiments where platform 100 is configured to process private labelpurchase card transactions, platform 100 may also include a cardholderdata store 130.

User interface 125 enables authorized personnel (generally, personsaffiliated with the acquirer or third-party provider) to performfunctions including updating data in merchant master data store 110 andcard product data store 117. User interface 125 may include hardware orsoftware security components (e.g., password authentication) to preventunauthorized use. In the embodiment shown, user interface 125 interactswith a display device for presenting information to a user, e.g., acomputer monitor 126, and a user input device for accepting input from auser, e.g., a keyboard 127. A user may access user interface 125directly or via a network connection such as a local area network,leased line, virtual private network, intranet or internet.

Platform 100 communicates with various external components to performmerchant processing functions. In the embodiment shown, platform 100communicates with one or more merchants 140; one or more cardassociations 142; and an electronic transaction clearinghouse 145, e.g.,the Federal Reserve Automated Clearinghouse (ACH) system. In someembodiments, platform 100 may also communicate with one or moreacquirers 150. Communication between platform 100 and the variousexternal components may take place over a variety of networks, includingleased lines, telephone lines, virtual private networks, or theInternet. Communication may also take place by the exchange ofcomputer-readable media, such as data tapes, recordable compact disks,and the like. Some communication may also be in paper form. Hardwareand/or software-based security components (not shown) such as firewallsand data encryption systems may also be provided.

It will be appreciated that the description of platform 100 isillustrative and that platform 100 and its associated functionality mayalso be implemented using more or fewer components than those describedherein. Based on the disclosure and teachings provided herein, a personof ordinary skill in the art will recognize other ways and/or methodsfor implementing the present invention.

In one embodiment of the present invention, platform 100 is operated bya third-party provider of merchant processing services and configured toprocess all purchase card transactions submitted by a particularmerchant. That is, platform 100 may process any transaction involvingany card product accepted by the particular merchant. In order toperform this function, platform 100 includes card product data store117, which stores a repository of information about card products thatmay be presented. The repository includes a master card product list,which will now be described.

FIG. 2 illustrates the contents of an exemplary master card product list200. Each entry in master card product list 200 defines a card type thatplatform 100 is capable of processing; master card product list 200preferably includes an entry for every card type that the third partyprovider recognizes. As will be apparent from the present disclosure, a“card type” entry in master card product list 200 provides a definitionof how platform 100 can process a transaction when a particular card ispresented. A card type may be defined for any arbitrary grouping ofcards, such as a card product, a group of card products that areprocessed in the same way, or a subset of the cards associated with aparticular card product. In addition, the same card product may beassociated with more than one card type; examples will be describedbelow. To manage the various options for transaction processing, mastercard product list 200 provides a number of fields of information relatedto each card type.

For instance, card type identifier 202 is a code that uniquelyidentifies each entry in master card product list 200. In oneembodiment, card type identifier 202 is a five-digit numerical code;alphanumeric codes of arbitrary length may also be used. Card typeidentifier 202 may be assigned arbitrarily or according to any desiredscheme.

Prefix field 204 contains information for use in determining the cardtype of a presentation instrument presented to a merchant. In oneembodiment, prefix field 204 contains one or more card prefixesassociated with a particular card product or group of card products; thecard prefix corresponds to the first few digits of the accountidentification number of a presentation instrument. As is known in theart, when card associations or issuers assign numbers to cardholderaccounts, the first few digits of the number are generally used toidentify the card product. For instance, assuming that card productsbelonging to a card association C always have numbers beginning with afour-digit sequence in the range from “6000” to “6999,” this four-digitsequence would be the card prefix for an association C card product.(The number of digits constituting the prefix may vary from one cardassociation to the next.) An industry standards organization (ISO)assigns blocks of prefixes to a card issuer or association at theissuer's or association's request. Thus, in some embodiments of thepresent invention, the card prefix is sufficient to uniquely identifythe issuer (and/or association) of the card and the card product. Inother embodiments, prefix block 204 may be supplemented or replaced withany other information obtainable from a merchant that can be used todetermine the card type of a presentation instrument.

In some cases, prefix block 204 may provide a reference to anothersource of prefix information. For instance, some card associations(e.g., the VISA and MASTERCARD associations) provide prefix tables thatare updated periodically; these tables identify all valid prefixesassociated with each card product authorized by the association. Mastercard product list 200 may either list such prefixes or refer to theassociation-provided prefix table.

Routing field 206 includes a destination to which transactions for aparticular card type are to be routed. Routing field 206 may alsoidentify a format to be used for transaction routing. In one embodiment,routing field 206 provides four items of information: authorizationformat, authorization destination, routing format, and routingdestination. This information may be provided using predefined codesthat map to each available routing destination and format option. Theuse of routing field 206 will be described below.

Name 208 is a human-readable identifier associated with card typeidentifier 202. Generally, name 208 reflects the name of a card issuer,association, or network responsible for the card product(s). Multiplecard types may have the same name; however, to facilitate userinteraction with master card product list 200, it is advantageous foreach name 208 to include some piece of unique information. In someembodiments, name 208 is provided as a convenience to users and has noeffect on transaction processing.

Settlement flag 210 indicates whether the third-party provider performssettlement (value “Y”) or not (value “N”) for this card type. This flagis used during processing to determine whether a transfer of funds fromthe acquirer to the merchant should be initiated, as will be describedbelow.

Transaction types field 212 contains one or more indicators of types oftransactions that the third-party provider supports for the card type.In one embodiment, the available transaction type indicators refer tothe standard transaction types recognized in the art, namely, sales(“S”), returns (“R”), cash advances (“C”), and payments (“P”). It shouldbe noted that any combination of the available transaction types may beallowed for a particular card type, depending on rules established bythe issuer of a particular card product or the applicable cardassociation. Thus, as described below, all of a merchant's purchase cardtransactions may be processed using the same merchant record, regardlessof the transaction type.

Other information may also be provided. For example, label field 214indicates a “label” to be associated with each card type. A label may beunique to a card type or may provide a convenient grouping of card typesfor reporting or other purposes. For instance, in FIG. 2, all card typesfor association V are assigned a label of “04,” all card types forassociation M are assigned a label of “01,” and all private label cardtypes, regardless of issuer, are assigned a label of “09.”

As another example, owner field 216 may be provided to identify theparty responsible for issuing accounts corresponding to the card type.Where platform 100 is operated by a third-party processor that alsoprovides card-issuer services, owner field 216 may be used where thecard issuer is a client of the third-party processor. Where informationabout the owner is not useful, the field may be left blank. Forinstance, the Retailer H private label card type has “Client 1”identified as its owner. Identification of the owner may be by means ofa code, a name, or any other identifier.

In an exemplary embodiment, platform 100 is under the control of athird-party provider of merchant services that maintains master cardproduct list 200. In this exemplary embodiment, the third-party providerhas a number of clients, each client being an acquirer that providespurchase card processing services to a number of merchants. Theseclients may desire (or be required) to process purchase cardtransactions for a particular presentation instrument in different ways.To support all such client preferences, a card product may be associatedwith multiple card types in master card product list 200. Some examplesare illustrated in FIG. 2.

In one example, the same card product (e.g., group of prefixes 204) mayappear in the master card product list 200 as two different card types202 having different routing destinations 206. For instance, supposethat an acquiring bank in the U.S. is able to route card transactionsdirectly to card association V, and suppose further that, due toCanadian banking laws, an acquiring bank in Canada is required to routesuch card transactions to another institution for forwarding to cardassociation V. Master card product list 200 includes two card types thatmay be used for association V card products (e.g., card types “04001”and “04002”); the two card types associate the same prefixes 204 withdifferent routing destinations 206. As will be described below, amerchant may be assigned one of these two card types, depending on theacquirer's needs or preferences.

In another example, the same group of prefixes 204 (corresponding, e.g.,to a card product) may appear more than once in master card product list200 with different routing destinations, thereby enabling co-brandedcard products to be provided. A co-branded card product bears two badgesand is processed differently depending on where it is used. Forinstance, suppose that retailer D and card association A agree thatretailer D may issue cards bearing both A's and D's badges. Theagreement provides that the card is to be recognized and processed asproduct of card association A everywhere except in retailer D's stores,where it is to be recognized and processed as retailer D's private labelcard. Card association A selects a subset of its ISO prefixes (e.g.,prefixes 395000-399999) to be used for the co-branded product.

To support this co-branded card product, master card product list 200can define two different card types associated with the selected prefixgroup. One card type (e.g., card type “05001”) associates the selectedprefixes (and other prefixes belonging to association A) with therouting destination for association A card products; the other card type(e.g., card type “09003”) associates the selected prefixes (but notother prefixes belonging to association A) with the routing destinationfor retailer D's private label card. As will be described below,merchants that are outlets of retailer D may be assigned the second cardtype, while other merchants are assigned the first card type. Becausethe card type definitions control processing, as described below, thesame card is processed differently by platform 100 depending on where itis presented.

Another example relates to electronic debit networks, which generally donot issue any cards or have any ISO-assigned prefixes. Instead, a debitnetwork provider enters into an agreement with a card issuing bank tohandle debit transactions involving other cards (e.g., interchangecards) issued by the bank. Such transactions are generally routedthrough the designated debit network rather than through a cardassociation interchange. To support electronic debit networktransactions, master card product list 200 defines card types 202 forelectronic debit cards as well. For these cards, prefix information maybe provided in prefix field 204; alternatively, prefix information maybe omitted (“n/a” in FIG. 2) and other methods may be used to identifythe card type of such cards upon presentation to a merchant. Examples ofprocessing debit network transactions will be described below.

It will be appreciated that master card product list 200 isillustrative, and that variations and modifications are possible. Mastercard product list 200 may be implemented using a database, one or moredata files (e.g., VSAM files), or any other data storage technology.Master card product list 200 may provide other information than thatdescribed herein, and information may be provided in any suitableformat. Master card product list 200 may also include more or fewer cardtypes and is not limited to the examples shown. Master card product listmay define card types for any combination of interchange card products,private label card products, electronic debit network card products, andany other category of card products. It is to be understood that a “cardtype” is defined by master card product list 200 and may correspond toany arbitrary grouping of purchase cards. A specific presentationinstrument may correspond to one or more card types.

In one embodiment of the present invention, master card product list 200is defined by a third party provider to include every possible cardproduct and transaction that the provider is capable of recognizing andprocessing. In general, because the third party provider acts as a proxyfor an acquirer, there need not be any agreement in effect between thethird party provider and a particular card association, network, orissuer. Master card product list 200 may be updated at any time (e.g.,via user interface 125) to add, change, or delete card type definitions.In some embodiments, card type definitions may be added, changed, ordeleted without requiring changes to any processing programs, except incases where new routing destinations and/or formats are added.

To manage the needs and preferences of acquirer clients, a separateclient-level card product list may be provided for each client. In oneembodiment, a client-level card product list has the same format asmaster card product list 200, but generally includes fewer card types.In embodiments where master card product list 200 includes all cards andtransactions that the third party provider is willing and able toprocess, each client-level card product list includes a subset of theentries in master card product list 200.

In an exemplary embodiment, a client-level card product list isgenerated by displaying master card product list 200 via user interface125 and prompting a user to select one or more card types from thedisplayed list. The display may include all fields in master cardproduct list 200 or any subset of the fields.

In some embodiments, a client-level card product list may includeentries for any number of card types and any combination of cardproducts, including interchange cards, electronic debit network cards,private label cards, and any other category of cards. Restrictions maybe placed on which card products from master card product list 200 maybe selected for inclusion in the client-level card product list. Forinstance, an agreement may be required between the client (i.e., theacquirer) and the card association providing for funds to be routedbetween the card association and the client in settlement oftransactions of a particular type. Similarly, in some embodiments, theclient may be limited to selecting only one routing destination for aparticular card association. For instance, master card product list 200includes two card types for association V (card types “04001” and“04002”). This signifies that the third-party provider provides twodifferent routing options for the cards of association V (more than twooptions could also be provided by defining additional card types). Anacquirer, however, may be required by its agreement with association Vto route all its transactions to the same destination; accordingly,selection from master card product list 200 may be limited to one of theavailable card types for association V. In other instances, aclient-level card product list may include two or more card typesassociated with the same prefixes (e.g., card types “05001” and “09003”could both be included).

In some embodiments, creation of the client-level card product list mayalso involve adjusting the settlement flag. A settlement flag value “Y”in master card product list 200 signifies that the provider is capableof performing settlement on the client's behalf. A particular client,however, may prefer not to have the provider perform this function, inwhich case the flag value may be reset to “N” in the client-level cardproduct list 200 for that client. (In this example, a settlement flagvalue of “N” in master card product list 200 would signify that theprovider does not perform settlement and would generally not beoverrideable at the client level.)

In one embodiment, a client-level card product list is created when thethird-party provider signs up a new client. The client-level cardproduct list may be updated when master card product list 200 is updated(e.g., when a new card product or a new option for processing existingcard products becomes available), as well as when the client'sagreements with various card issuers, associations, or networks change.

It should be noted that providing a client-level card product list isoptional. In some embodiments, such a list may facilitate building ofmerchant card type lists and processing of transactions, as will bedescribed below. In embodiments where there is no third-party provider,master card product list 200 would be under the direct control of anacquirer and would reflect the particular processing preferences of theacquirer; accordingly, a separate client-level card product list can beomitted.

In order to control transaction processing on a merchant-by-merchantbasis, card type information is also provided for each merchant. Anembodiment of merchant card type information will now be described. Asnoted above, platform 100 includes a merchant master data store 110. Inone embodiment, data store 110 contains a record related to eachmerchant for which processing services are provided by platform 100.Merchant master data store 110 is used by various merchant processingapplications, examples of which will be described below. Merchant masterdata store 110 is maintained by an acquirer or by a third-partyprovider. (Optionally, a merchant may be authorized to update certaininformation in merchant master data store 110 directly.)

An exemplary embodiment of a merchant record 300 in merchant master datastore 110 is shown in FIG. 3. The information in merchant record 300 isorganized into a number of sections, each containing one or more fields.General information section 305 includes the merchant's name and contactinformation, including an address for the merchant. General informationsection 305 also includes a merchant identifier, such as a number oralphanumeric code, that uniquely identifies the merchant record 300. Themerchant identifier may also identify the merchant's location within ahierarchical grouping of merchants, as will be described below. If themerchant is an outlet in a chain of stores, a chain code may be used toindicate the merchant's association with the chain. Where a chain codeis provided, all merchants in a particular chain share the same chaincode. As will be described below, chain codes may be used to implementcommon card type acceptance rules for all outlets of the chain.

Merchant master record 300 also includes a merchant card typeinformation section 320. This information either includes or can be usedto build a merchant card type list 400, an example of which is shown inFIG. 4. Merchant card type list 400 establishes the card types that amerchant is allowed to accept, the allowed transaction types for eachcard, and other information used by platform 100 to process transactionsfor the merchant. In one embodiment, each entry in merchant card typelist 400 includes a card type identifier 402, a set of prefixes 404associated with the card type identifier, an authorizations flag 406, atickets flag 408, a reimbursement flag 410, an Automated Clearinghouse(ACH) flag 412, and a transaction type indicator 414. As will bedescribed below, the various fields in merchant card type list 400 areused to control processing of all card product transactions submitted bythe merchant.

Card type identifier 402 is one of the card type identifiers 202appearing in master card product list 200 described above. As will bedescribed below, card type identifier 402 serves as a link betweentransaction processing parameters that are maintained at the merchantlevel and additional transaction processing parameters that aremaintained at the acquirer or third-party provider level.

Prefix field 404 identifies one or more card prefixes (or blocks ofprefixes) that map to the corresponding card type identifier 402 for themerchant. In general, prefix field 404 for a particular card typeidentifier 402 is the same as the prefix field 204 corresponding to thesame card type identifier 202 in master card product list 200; in someembodiments, exceptions may be made, as will be described below.

Merchant card type list 400 also includes merchant-specific informationthat is not included in master card product list 200. This enablesfurther tailoring of transaction processing to the specific requirementsand preferences of individual merchants and acquirers. For example, asis known in the art, some merchants are permitted to submit bothauthorizations and tickets for processing for a particular card product,while other merchants are allowed to submit only one of the two. Inmerchant card type list 400, authorizations flag 406 and tickets flag408 indicate whether the merchant is allowed to submit authorizationtransactions and ticket transactions, respectively.

Similarly, different merchants may be authorized to accept differenttransaction types (e.g., sales, returns, cash advances, and payments).Transaction types field 414 includes an indicator for each of one ormore transaction types that the merchant is allowed to accept for thecard type associated with card type identifier 402. The indicators usedare preferably the same as for transaction types field 212 in mastercard product list 200. It should be noted that transaction types field414 in merchant card type list 400 may include all, some, or none of thetransaction types that appear in the corresponding field 212 of mastercard product list 200.

Reimbursement flag 410 and ACH flag 412 are used during processing oftransactions involving funds transfers to control whether, how, and whenfunds are transferred. The use of these flags will be described below.

It will be appreciated that merchant card type list 400 is illustrative,and that variations and modifications are possible. Merchant card typelist 400 may be maintained as a structure within merchant master record300, or in a separate data file (e.g., a VSAM file) that can beaccessed, for example, by using the merchant identifier or via a linkfrom merchant master record 300. In one embodiment, data for merchantcard type list 400 is maintained in merchant master record 300 inmerchant master data store 110, and a VSAM file for each merchant isperiodically back-built from merchant master data store 110. Theback-building process may also use other information stored in cardproduct data store 117. One such process will be described below.

Merchant master record 300 may also include any other information neededto process and report the merchant's purchase card activity. One exampleof a merchant master record is described in further detail in co-pendingU.S. patent application Ser. No. ______ (Attoriey Docket No.020375-005900US), filed _, the disclosure of which is incorporatedherein by reference.

It will be appreciated that merchant record 300 is illustrative, andthat the content and arrangement of merchant record data may be variedin specific embodiments. Moreover, merchant master data store 110 may beimplemented using any suitable data management technology, includingwell-known database products.

In some embodiments of the present invention, merchant records 300within merchant master data store 110 may be organized hierarchicallyfor reporting or other purposes, including establishing which card typesa merchant is authorized to accept, as will be described below. Anexample of a hierarchical organization 500 is shown in FIG. 5A. At thetop of the hierarchy 500 is a third-party provider 502. The third partyprovider provides services to clients (acquirers) 504. Each clientprovides purchase card processing services for a number of merchants506. Each merchant 506 has a corresponding merchant record 300 inmerchant master data store 110. The hierarchical organization 500provides for intermediate groupings of merchant accounts, labeled (indescending order) “System” 508, “Principal” 510, “Agent” 512, and“Headquarters” 514. Not all intermediate groupings need be present; forinstance, client “1” has a headquarters 514 without a system, principal,or agent. Client “2” has agents 512 without a system or principal.

In general, hierarchical organization 500 allows a client 504 toorganize its portfolio of accounts for merchants 506 in any convenientmanner by establishing structure at some or all of the interveninglevels. For instance, a client 504 may elect to group together alloutlets of a chain by associating all such merchants with a commonheadquarters 508. Agents 512, principals 510, and systems 508 eachrepresent successively larger groupings of merchant accounts 506, andreporting of account status and activity may be provided to the clientat each of these levels. Acquirers may use hierarchy 500 to organizetheir merchant account portfolios by industry, geography, associationwith affiliate banks, or any other common threads. Thus, hierarchy 500may be used by an acquirer or third-party service provider to manage alarge portfolio of merchant accounts without implementing multiplemerchant databases.

In some embodiments, the merchant identifier in merchant record 300reflects the hierarchical structure. For instance, as illustrated inFIG. 5B, a merchant identifier 550 may be a numerical code made up ofseveral blocks of digits. A first block 552 indicates a client 504 ofthe third-party provider, a second block 554 indicates a system 508, athird block 556 indicates a principal 510, and a fourth block 558indicates an agent 512. A fifth block 560 is used to uniquely identifymerchant accounts 506 within the agent level. In this embodiment, aheadquarters 514 (if one is defined) is identified by a separate chaincode within merchant master record 300; alternatively, association witha headquarters could be indicated by an additional block of digits inmerchant identifier 550. If a hierarchical level is absent, thecorresponding block of digits may be set to all zeroes or anotherdefault value.

In some embodiments, hierarchy information may be used in determiningthe card types that a merchant is allowed to accept, as will bedescribed further below. It will be appreciated that the hierarchypresented here is an example, and that merchant processing systemsaccording to the present invention may be implemented with otherhierarchies or with no hierarchy.

Hierarchy 500 may be used to simplify building of merchant card typelists 400, as will now be described. FIG. 6 illustrates a process 600for building a merchant card type list 400 using information stored inmerchant record 300 as well as one or more default card type listsstored in card product data store 117. FIG. 7 illustrates specificexamples of card type lists that could be used in or generated byprocess 600. In general terms, process 600 involves defining defaultcard type lists for various hierarchical levels and causing merchantcard type lists to inherit the contents of an appropriate default list.

More specifically, at step 602, a client-level card product list isdefined, e.g., prompting a user to select one or more card types from amaster card product list, as described above. FIG. 7 illustrates twoclient-level card product lists 702, 704 for two clients (“Client #1”and “Client #2”) that could be generated from a third-party providermaster card product list 700. For clarity of presentation, the card typelists in FIG. 7 include only a card type identifier and a name; it is tobe understood that other information may also be included; for instance,the format of master card product list 200 and/or merchant card typelist 400 could be used. In some instances, step 602 may involveaccessing a previously defined client-level card product list stored incard product data store 117.

At step 604, one or more default card type lists are generated. Theselists may have the same format as merchant card type list 400 describedabove. Each default card type list is associated with a particularlocation in a merchant hierarchy 500 defined by the client. Forinstance, in FIG. 7, “Client #1” has defined a default card type list706 for a system “1.1,” a default card type list 708 for a principal“1.1.1” and a default card type list 722 for a headquarters of a chainof retailers P. “Client #2” has defined a default card type list 710 foran agent “2.1,” a default card type list 712 for another agent “2.2,”and a default card type list 720 for a headquarters of a chain ofmerchants Q. Each default card type list has entries corresponding tosome (or all) of the card types included in the respective client'smaster card product list 702, 704. A client may define a default listfor some or all of the hierarchical locations it has defined. In someinstances, step 604 may involve accessing one or more previously defineddefault card type lists stored in card product data store 117.

In one embodiment, a default card type list (e.g., list 706) is definedby displaying the appropriate client-level card product list (e.g., list702) via user interface 125 and allowing a user to select one or morecard types to be included in the default card type list. Default cardtype lists generally include all of the information provided in merchantcard type list 400. Some of this information (e.g., authorization,ticket, and reimbursement flags) might not be included in theclient-level card product list. Thus, upon addition of a card type tothe default card type list, the user may be prompted to supply thisinformation. Default values for the additional fields could also beprovided, with the user having the ability to override the defaultvalues. It will be appreciated that any card type included in theclient-level card product list may be included in a default card typelist for that client.

In an exemplary embodiment, building card product and card types lists(steps 602 and 604) occurs as circumstances warrant, e.g., when anacquirer's agreements with various card issuers, associations, andnetworks change. The default card type lists may be stored in cardproduct data store 117 and accessed periodically for building ofmerchant card type lists.

At step 606, the merchant record 300 for a particular merchant isaccessed. In one embodiment, merchant record 300 includes at least acard type identifier corresponding to every card type the merchant isallowed to accept. Alternatively, the merchant card type list “inherits”card types from one (or more) of the default card type lists.

To determine whether the merchant card type list for a particularmerchant is to include inherited card types, at step 608, merchantrecord 300 is checked for an “only” flag, which indicates that no cardtypes are to be inherited. In one embodiment, the “only” flag is storedin association with one or more card types included in card typeinformation section 320 of merchant record 300.

If the “only” flag is not asserted, then at step 612 the merchant cardtype list inherits one or more card types from a default card-type listat a higher hierarchical level. For example, merchant card type list 718inherits three card types (indicated by italic type) from agent-leveldefault card type list 712. In one embodiment, each merchant inheritsfrom only one default card type list. For example, merchant card typelist 714 inherits only the card types in principal-level default cardtype list 708; the system-level default card type list 706 is notinherited, and consequently merchant card type list 714 does not includethe association A card type.

At step 614, any card types expressly included in merchant record 300are added to the inherited list. For example, merchant card type list728 includes the card types for retailer H and retailer P in addition tothe four card types inherited from agent-level default card type list710. In general, any card type included in the client-level card productlist may be added to the merchant card type list for any merchant. Thus,one merchant may be able to accept any combination of card types.

If the “only” flag is asserted, then at step 610, the merchant card typelist 400 is built including only those card types expressly included inmerchant record 300, regardless of any default card type list that mayexist. For example, in FIG. 7, merchant card type list 730 includes onlythe association M and association V card types, with the “only” flag.Merchant card type list 730 does not inherit the association A card typefrom agent-level default card type list 712.

In some embodiments, the headquarters level is handled differently fromother intermediate levels of the hierarchy. For instance, while aprincipal-level default card type list is not built by inheriting asystem-level default card type list, a headquarters-level card type listcan be built by inheritance. For example, headquarters-level card typelist 720 inherits card types from agent-level default card type list712. The headquarters-level card type list may also include card typesother than the inherited types; for instance, headquarters-level cardtype list 720 adds the “association J” card type. Alternatively,headquarters-level card type lists may be established withoutinheritance, e.g., headquarters-level card type list 722. Merchantsassociated with a chain generally inherit card types only from the chainheadquarters; e.g., merchant card type list 724 inherits fromheadquarters-level card type list 722, and merchant card type list 726inherits from headquarters-level card type list 720.

In an exemplary embodiment, a merchant card type list 400 provides aunique mapping from a card prefix to a card type identifier. In manyinstances, card issuers and associations select prefixes according tostandards established in the industry (“ISO standards”), which aredesigned to allocate prefixes uniquely among various issuers andassociations. (For instance, under one set of rules known in the art,any ISO-compliant presentation instrument whose first digit is “4” is aVISA product; any card whose first digit is “5” is a MASTERCARD product,and so on.) In cases where an issuer chooses to ignore the ISO standards(e.g., a private label issuer who does not want its cards to be widelyaccepted), however, duplication of prefixes is possible. It is alsopossible to have duplication of prefixes at the client level, e.g.,because of the need to accommodate different processing proceduresand/or acceptance of non-ISO-compliant card products for differentmerchants.

Thus, process 600 may include error-checking to verify that the mappingfrom card prefixes to card type identifiers within a merchant card typelist 400 is unique. In the event that adding a card type causes a prefixto map to two card type identifiers, a warning is generated and the useris required to remove one of the card types. In an alternativeembodiment, duplication is allowed, and the merchant is required toprovide additional information besides the card number in order tocomplete a transaction, as will be described further below. In general,any such information can be stored as part of prefix field 404 inmerchant card type list 400, or in a separate field used in conjunctionwith prefix field 404.

As described above, inheritance can be prevented using the “only” flagfor a particular merchant. Inheritance can also be prevented at theclient level. For example, a client may prefer to allow only selectedmerchants to accept a particular card product; e.g., the client may wantonly retailer P's stores or a few selected other retailers to acceptretailer P cards. To prevent inheritance that might inadvertently enablenon-selected merchants to accept the card product, the client may set a“Limited” flag in the client-level card product list, as indicated inlists 702, 704. The “Limited” flag prevents inadvertent inheritance byindicating that the card type is not to be inherited. Thus, regardlessof any hierarchical structure, merchants do not inherit this card type.To permit inheritance, the card type must be expressly added to a listat a lower level, without the “Limited” flag. For instance,headquarters-level card type list 722 (the chain headquarters forretailer P) includes the retailer P card type without the “Limited”flag; thus merchant card type list 724 can inherit the retailer P cardtype despite the “Limited” flag in client-level card product list 702.

It is to be noted that the content of a merchant card type list is notrestricted. In general, any card product may be included in any merchantcard type list, regardless of the card association, the interchange orprivate label status of the card product, the allowed transaction types,or other such considerations. Further, the presence or absence of aparticular card type from any default card type list does not preventthe card type from being included in a merchant card type list. It willbe appreciated that appropriate agreements between the parties (i.e.,merchant, acquirer, and card issuer or association) should generally bein place before allowing a merchant to accept a particular card type,but once those agreements are in place, platform 100 is able to supportthe merchant's acceptance of the issuer's products, regardless of theissuer's identity. Thus, merchant card type lists 724, 728 are each ableto include both the retailer P and retailer H card types.

It will be appreciated that process 600 is illustrative, and thatvariations and modifications are possible. For instance, it is notnecessary to generate new client-level card product lists or defaultcard type lists every time a merchant card type list is to be generated.Such lists may be stored in card product data store 117 and accessed forpurposes of building merchant card type lists. Depending onimplementation, generation of merchant card type lists may be doneperiodically for all merchants and/or on demand for one or moremerchants in response to a user request. In addition, default card typelists are not required; a merchant card type list could be populatedmanually for each merchant. It should be noted, however, that manualpopulation of merchant card type lists may increase the data-entryburden when creating new accounts. Any number of default card type listsmay be created, and a client may, for example, have default card typelists for some of its systems (or principals or agents) but not all.

Examples of processing purchase card transactions (authorization, ticketacquisition, and settlement) using platform 100 and merchant card typelist 400 for a particular merchant will now be described.

FIG. 8 is a flow chart of an exemplary process 800 for an authorizationtransaction according to the present invention. During authorization,the merchant processing platform 100 first determines whether themerchant is authorized to accept the presentation instrument (or card)presented by a customer. The merchant is authorized to accept the cardif a corresponding card type appears in the merchant card type list andthe transaction-type indicator corresponding to the contemplatedtransaction (e.g., sales if the card is presented for a purchase) ispresent. Then the validity of the cardholder's account is determined,generally by routing the authorization request to the card associationor issuer for approval. The process results in an approval or denialmessage being returned to the merchant. From the merchant's perspective,all card products may be handled in the same way; for instance, themerchant may have one point-of-sale (POS) terminal used to swipe allcards and transmit appropriate information to the acquirer.

More specifically, at step 804, transaction data for the authorizationtransaction is received from the merchant, e.g., via transmission from aPOS terminal over a dialup connection. The transaction data includes atleast an identifier of the merchant, the account number of thepresentation instrument, and an indication of the transaction type ofthe proposed transaction for which authorization is sought (e.g., sales,cash advance, payment). Other information, such as a proposedtransaction amount and transaction-specific information (e.g., anitinerary in the case of an authorization for an airline ticketpurchase) may also be included. Various techniques for providingtransaction data are known in the art and may be employed to providetransaction data to process 800. At step 808, the merchant card typelist for the merchant is retrieved. For instance, the data received atstep 804 may include a numerical merchant identifier that can be used atstep 808 to access a VSAM file containing the merchant card type list.

At step 812, a prefix is extracted from the account number of thepresentation instrument. The prefix may be defined as an arbitrarynumber (e.g., up to 15) of digits starting from the first digit in theaccount number. The prefix generally includes enough digits tounambiguously match the presentation instrument to one of the card typesin the merchant card type list for the merchant.

At step 814, the prefix is compared to the various prefix fields 404included in merchant card type list 400 for the merchant. If a matchingprefix is found in merchant card type list 400, the corresponding cardtype identifier 402 is selected as the card type for the transaction. Atstep 816, if no card type has been found, then the process checksexternal card prefix tables (e.g., the association V table) at step 818.Process 800 may be implemented so that checking of external card prefixtables is conditioned on certain events. For instance, in oneembodiment, a particular external card prefix table is checked only ifmerchant card type list 400 indicates that the merchant accepts cardslisted in that table; e.g., the association V card prefix table would bechecked only if merchant card type list 400 for a particular merchantcontains a card type that references the association V card prefixtable. Also, the process may be implemented so that the external tableis checked only for prefixes where a match is possible; e.g., ifassociation V uses only prefixes beginning with “4”, then theassociation V prefix table would be checked only if the first digit ofthe presentation instrument's prefix is “4”. At step 820, if no cardtype matching the prefix of the presentation instrument has been found,the authorization request is denied at step 822. A denial message isreturned to the merchant; preferably, the denial message also informsthe merchant that the card is not of a type the merchant is allowed toaccept.

At step 824, having determined the card type, the correspondingauthorizations flag 406 in merchant card type list 400 is checked todetermine whether the merchant is allowed to submit authorizationtransactions for the card type 402. If not, the authorization request isdenied at step 822, preferably with a message indicating that themerchant cannot submit authorization transactions for the card type. Itshould be noted that because the authorizations flag for a card type iscontrolled at the individual merchant level, platform 100 can processtransactions for all merchants, regardless of whether each merchant isallowed to submit authorization tickets for a particular card type.

At step 828, the proposed transaction type received in the transactiondata is compared to the list of supported transaction types 404 for theidentified card type 402 in merchant card type list 400 to determinewhether the merchant is allowed to submit transactions of the proposedtype. If the transaction type is not allowed, the authorization requestis denied at step 822, preferably with a message indicating an invalidtransaction type. It should be noted that because allowed transactiontypes for a card type are controlled at the merchant level, platform 100can process transactions for all merchants, regardless of whichcombination of transaction types each merchant is allowed to accept fora particular card type.

Successful completion of step 828 establishes that the merchant isallowed to accept cards of the type presented for transactions of thecontemplated type. The remaining steps deal with validating thecardholder's account by providing the card issuer or association withthe transaction data. In appropriate circumstances, these steps may beomitted (e.g., if the card issuer's rules do not require advancevalidation of the account).

At step 832, a routing destination and format are determined based onthe card type identifier. In one embodiment, this is done by using thecard type identifier to retrieve a routing field from the client-levelcard product list. In an alternative embodiment, merchant card type list400 is built to include a routing field (e.g., by duplicating therouting field from the client-level card product list). The routingfield identifies a routing destination and may also include formattinginformation so that the authorization request can be transmitted in anappropriate format. At step 834, the authorization request istransmitted to the routing destination; any required formatting is doneprior to transmitting the request. At step 836, a response is receivedfrom the card issuer or association. The response generally includes anapproval or denial and may include other information, such as anauthorization number (in the case of an approval), an indication of areason for denial, or a request to instruct the cardholder to contactthe card issuer. At step 838, the response is forwarded to the merchant.

It will be appreciated that process 800 is illustrative and that processsteps described herein may be modified or varied. For instance, steps824 and 828, each of which involves checking the merchant card type list400, may be combined. Process 800 is, in general, unaffected by anyparticular authorization procedures that may be used by a card issuer orassociation to decide whether to grant or deny a request. Process 800may also include additional steps related to reporting or logging ofauthorization activity, including approvals, denials, and the basis forany denials, as well as other steps known in the art.

In some embodiments, platform 100 may also process purchase cardtransactions via electronic debit networks in addition to (or insteadof) card associations. As described above, debit networks generally donot own any card prefixes or issue any cards; instead, debit networkproviders enter into agreements with individual banks to associatethemselves with that bank's card products, which are typically issuedunder prefixes established by a card association.

FIG. 9 illustrates an exemplary embodiment of a process 900 fordetermining a card type for a transaction that is to be handled via adebit network. Such transactions are distinguishable from othertransactions by the presence of a “PIN block” (an encoded version of thepersonal identification number, or PIN, that the cardholder is requiredto enter before the merchant submits the transaction) in the transactiondata. When a transaction is received at step 902, process 900 firstchecks for the presence of a PIN block (step 904).

At step 906, when a PIN block is detected, the appropriate debit networkis selected. A number of techniques for selecting a debit network areknown in the art. In one embodiment, each acquirer that accepts debitnetwork transactions has agreements with one or more networks andprioritizes the networks according to fees charged and/or othercriteria. When a presentation instrument is associated with multipledebit networks, the priorities established by the acquirer are used todetermine which of the networks is to process the transaction. In oneembodiment, platform 100 does not select the network, but insteadcommunicates with an outside agency (e.g., Electronic Data Systems) thatperforms the appropriate network selection operation and returns anidentifier of the selected network to platform 100.

At step 908, process 900 locates the network identifier in merchant cardtype list 400, thereby determining the card type for the transaction.Once the card type is determined via process 900, processing of debitnetwork transactions may proceed similarly to the processing describedabove with regard to FIG. 8, beginning at step 824.

It will be appreciated that process 900 is illustrative and may bemodified or varied. For instance, platform 100 can include theinformation needed to select an electronic debit network without usingan outside agency; such processes are known in the art.

In addition, processes 800 and 900 can be combined. In the combinedprocess, upon receipt of a transaction, platform 100 first searches fora PIN block in the transaction data. If no PIN block is found, then thecard type for the transaction is determined using steps similar to steps808 through 820 described above. If a PIN block is found, then stepssimilar to process 900 are invoked to determine the card type. Once thecard type is known, processing of both sorts of transactions may followthe same steps.

FIG. 10 is a flow chart of an exemplary process 1000 for processing ofticket acquisition and settlement by platform 100. The process will bedescribed for the case where platform 100 is operated by a third-partyprovider of merchant services; it will be appreciated that a similarprocess could be implemented in the case where platform 100 is operatedby an acquirer. In on embodiment, platform 100 receives a batch oftickets from a merchant. Each ticket corresponds to a merchant-customertransaction and includes the account number of the presentationinstrument, the transaction type, and the transaction amount. The ticketmay also include other information, such as an authorization code, thetransaction date, transaction details (e.g., an itinerary if thetransaction relates to an airline ticket purchase), and so on. The batchmay include transactions of any allowed type using any allowed cardproduct in any order. Each ticket is extracted from the batch in turn,processed, and routed to the appropriate card issuer, association, ornetwork.

More specifically, at step 1002, a batch of tickets is received from amerchant. It is to be understood that step 1002 may also includepre-processing steps such as matching tickets to authorization records,conversion of paper tickets to electronic form, and the like. At step1004, a ticket is extracted from the batch, and at step 1006 the cardtype is determined. Determination of card type at step 1006 generallyinvolves using the merchant card type list 400 for the merchant and mayproceed in a manner similar to the card-type determination steps ofprocess 800 described above. Where debit-network transactions are alsoprocessed, the card-type determination steps of process 900 may be usedas well. As noted above, processes 800 and 900 may be combined so thatthe card type can be determined for any presentation instrument. At step1008, the card type identifier is added to the transaction data. If thecard type cannot be determined at step 1006, the transaction is rejectedat step 1010. Procedures for handling rejected transactions are known inthe art and generally include notifying the merchant that thetransaction was rejected.

At step 1012, the tickets flag 408 corresponding to the identified cardtype 402 in merchant card type list 400 is checked to determine whetherthe merchant is allowed to submit tickets for the identified card type.If not, the transaction is rejected at step 1010. At step 1016, thetransaction type submitted by the merchant is checked against theallowed transaction types 414 for the identified card type 402. Again,if the merchant is not allowed to accept transactions of the submittedtype, the transaction is rejected at step 1010. Steps 1012 and 1016 maybe implemented similarly to steps 824 and 828 of process 800 describedabove.

If the card type and transaction type are valid for the merchant, thetransaction is processed. At step 1020, a routing destination isdetermined and added to the transaction data. As described above withregard to process 800, the routing destination may be determined byreference to a client-level card product list; in an alternativeembodiment, the routing destinations are stored in merchant card typelist 400 and determined from that list.

At step 1024, the transaction data is formatted appropriately, asdetermined by routing information parameters associated with theidentified card type. In one implementation, a routing informationparameter is used as a switch to select from a group of availableformatting processes. Formatting of transaction data may be done usingany suitable techniques, a number of which are known in the art.

In some embodiments, formatting of the transaction data includesdetermining an account identifier under which the ticket is to bereported to the card issuer, association, or network. For example, insome embodiments, platform 100 identifies merchants and acquirer clientsusing internal numerical identifiers. These identifiers might not matchthe identifiers assigned to the same merchants and acquirers by cardissuers or associations (e.g., “ICAs” assigned by MASTERCARD or “BINs”assigned by VISA). Thus, before routing the transaction data to the cardissuer, it is necessary to attach an identifier of the acquirer and/ormerchant that the card issuer or association can recognize.

In one embodiment, the determination of an issuer-side identifier isaccomplished using a Combined Deposit Table. The Combined Deposit Tablemaps a combination of the merchant identifier (or a portion thereof) andcard type to a reporting identifier to be used for reporting and routingof transactions. The Combined Deposit Table may be configured to returna result for any merchant/card-type combination; in instances where theresult is not needed for routing, it may still be used for reportingpurposes. In this way, the merchant identifier used by platform 100 ismade independent of identifiers that may be required by a card issuer,association, or network to which the transaction is routed. Thus,platform 100 may process any card type for any merchant withoutmaintaining multiple merchant records under different merchantidentifiers.

At step 1030, the transaction is routed to the routing destination. Insome embodiments, platform 100 may also handle issuer-side processingfor certain card types (e.g., some private label card products), inwhich case the routing destination is platform 100. In other cases, thetransaction may be routed to other platforms operated by the operator ofplatform 100 or to outside destinations operated by various cardissuers, associations, and networks. In general, step 1030 may involveaccumulating data for multiple transactions involving the same cardtype(s) and transmitting data in batches. As is known in the art,transactions may be batched at the level of merchants or using any otheruseful grouping (e.g., all transactions for a client). Multiple batchesmay be accumulated in parallel for different routing destinations,and/or for different transaction types (e.g., sales could be accumulatedin a batch separate from payments) according to the requirements of thecard issuer, association, or network. Thus, tickets may be processed inany order.

At step 1034, accounting operations are performed. In general, theseoperations include tracking balances owed to the merchant by theacquirer or the card issuer and generating any necessary funds transfertransactions, as well as reporting account activity to the acquirerand/or merchant. In an embodiment of the present invention, transactionsfor all card types may be handled by a similar accounting process. Anexample of accounting steps is shown in FIG. 11; these steps mayconstitute part of step 1034. First, the reimbursement flag 410 inmerchant card type list 400 is checked (step 1102) to determine whetherthe client (i.e., the acquiring bank) pays the merchant for thetransaction (step 1104). The reimbursement flag reflects the agreementsin place between the merchant and the card issuer or association,including applicable card issuer or association rules. If it isdetermined at step 1104 that the client does not pay the merchant (as isgenerally the case for certain card associations, e.g., AmericanExpress), then the transaction amount is added to a running total of“non-settled” transaction amounts for the batch (step 1106). Typically,the card issuer reimburses the merchant directly for such transactions;accumulating and reporting the total is a convenience to assist themerchant in its bookkeeping.

If it is determined at step 1104 that the client pays the merchant, thenat step 1108, a reimbursement amount is determined. The reimbursementamount may be the full transaction amount, or the acquirer may deduct apercentage (the discount rate) from each transaction. In someembodiments, the discount rate may be made to depend on the card type.This could be done, for instance, by providing a discount rate field inthe client-level card product list and/or the merchant card type list.For each ticket, the appropriate discount rate based on the card typewould be obtained from the list and applied.

At step 1110, the settlement flag is checked to determine how the fundsare to be transferred to reimburse the merchant. In one embodiment, thethird-party merchant processing provider may have an agreement with theacquirer to generate electronic funds transfer transactions on behalf ofthe acquirer for some or all card types. Such agreements are reflectedby the settlement flag for each card type in the client-level cardproduct list. (In some embodiments, this flag may be duplicated inmerchant card type list 400 for each card type accepted by themerchant.) At step 1112, it is determined from the value of thesettlement flag whether the third-party provider has agreed to generatea funds transfer transaction for the card type. If the settlement flaghas value “Y,” then the reimbursement amount computed in step 1106 isadded to a “net settled” total at step 1114. If the settlement flag hasvalue “N,” then the reimbursement amount is added to a “direct settled”total at step 1116. Upon completion of the batch, an electronic fundstransfer transaction (e.g., an ACH transaction) for the “net settled”total from a designated client account to the merchant account isgenerated. The “direct settled” total is not automatically transferred;instead, it is reported to the acquirer, who then transferscorresponding funds by any desired method.

It should be noted that for reporting purposes, the net settled, directsettled and non-reimbursed totals may each include a breakdown of eachtotal by card type and/or transaction type. Such breakdowns may beprovided to acquirers and/or merchants to aid them in assessing thefinancial performance of their purchase card operations. In addition,separate electronic funds transfer transactions may be generated fordifferent transaction types and/or card types; it will be appreciatedthat accumulating amounts for various transactions together and thengenerating a single electronic finds transfer transaction reduces thenumber of such transactions that are generated.

Returning to process 1000, after the routing (step 1030) and accounting(step 1034) processes are complete, it is determined at step 1040whether more tickets remain in the batch. If so, the process returns tostep 1004 to extract the next ticket. If not, end-of-batch processing isperformed at step 1042. Depending on implementation, this may includegenerating reports, transmitting transaction data to routingdestinations, and generating one or more electronic funds transfertransactions (e.g., for “net settled” amounts).

It will be appreciated that process 1000 is illustrative and may bemodified or varied. Steps not described in detail may be implementedusing any suitable techniques, a number of which are known in the art.In some implementations, authorization and acquisition may be performedconcurrently for some or all card types, in accordance with rulesestablished by various card issuers, associations, and networks.Further, acquisition of tickets need not be performed in batch;individual tickets could be presented by the merchant and processed byplatform 100 as customer transactions are completed. Totals could beaccumulated on a daily (or other periodic) basis for reporting and/orgenerating funds transfer transactions. In view of the presentdisclosure, a person of ordinary skill in the art will recognize otherways and/or methods of implementing transaction processing controlled byparameters associated with card type identifiers.

In some embodiments of the present invention, platform 100 is able toprocess all card types recognized by a third-party provider of merchantservices and all transaction types for each recognized card type.Consequently, there is no need for the third-party provider to maintainmultiple records for the same merchant; all of a particular merchant'sprocessing needs may be supported using a single merchant record 300maintained on a single platform 100. Of course, in the case of a largethird-party provider with many clients, it may be desirable to maintainmultiple platforms 100, but a record for a particular merchant wouldonly need to be accessible by one such platform.

In some cases, the third-party provider may also provide card-issuerservices to an issuer; the option of routing transactions for thatissuer's card products directly to another one of the third partyprovider's platforms may result in increased efficiency for settlementprocessing. For example, the third party provider can maintaincardholder account records for a private-label card product (e.g.,retailer P) on one of its platforms 100 (using cardholder data store130). Merchant records for retailer P's outlets can be maintained on thesame platform 100 or a different platform 100, with appropriate routingdestination parameters for card types corresponding to the product.

Accordingly, some embodiments of the present invention offer thepossibility of expanded acceptance of private label card products atlocations not directly associated with the issuer. For instance, byexploiting the ability to designate a routing destination for any cardtype, acceptance of retailer P's private label card products could beexpanded to merchants other than retailer P's outlets, regardless ofwhether account records for those merchants are on the same platform 100as retailer P's cardholder records. Thus, a cardholder who has retailerP's private label card may be able to use that card for “cross-shopping”at other stores. For instance, in FIG. 7, “Client #1” may be anacquiring bank that also issues retailer P's private label cards, and“Client #2” may be a different acquiring bank that also issues retailerH's private label cards. A merchant card type list, such as list 728 formerchant H or list 724 for merchant P, may include both of these cards,meaning that merchants H and P are able to accept each other's cards, aswell as their own card and any other card types in their respectivelists. Thus, a cardholder who has merchant P's private label card canuse it at merchant H's outlets as well as merchant P's, and vice versa.

As long as the card products appear as card types on the master cardproduct list, platform 100 can support acceptance of that card by anymerchant using processes such as those described above. Thus,essentially unlimited cross-shopping is made possible without requiringmerchant records to be maintained for the same merchant on multipleplatforms or under multiple merchant identifiers.

It is to be understood that such cross-shopping arrangements are notrequired by the present invention; in general, cross shopping betweenretailer H and retailer P (or any other issuers) would be implementedonly if the two retailers desired it and entered into an appropriateagreement. Once that agreement is in place, however, the third partyprovider (or acquirer) would be able to support the desired arrangement.Those of skill in the art will appreciate that there are variouscircumstances in which such arrangements would be desirable.

Another feature provided by some embodiments of the present invention isthe ability to support a “co-branded” card product. A co-branded cardproduct bears badges of two different entities, such as a cardassociation (e.g., card association A) and a retailer (e.g., retailerD). Under the terms of a co-branding arrangement, the co-branded cardproducts is to be processed as retailer D's private label card when themerchant is one of retailer D's outlets; for all other merchants, thecard product is to be processed as an association A card product.

To support such an arrangement, suitable card types may be defined inmaster card product list 200. For instance, card association A maydesignate a block of its ISO-assigned prefixes as identifying theco-branded card product. As shown in FIG. 2, the prefixes so designatedmay be associated with two different card types in master card productlist 200: the association-A card type “05001” and the retailer-D cardtype “09003”. Each type has a different routing destination and may havedifferent values for other fields. For merchants that are retailer D'soutlets, card type “09003” (retailer D card) is included in merchantcard type list 400. Upon receipt of a transaction using the co-brandedcard product from one of retailer D's outlets, the prefix is mapped tothe retailer D card type by the processes described above. Becausetransaction processing is controlled by parameters associated with thecard type determined from the merchant card type list, the transactionis processed as a retailer D private label card transaction. For othermerchants, the association A card type “05001” may be included inmerchant card type list 400. Upon receipt of a transaction using theco-branded card from such a merchant, the prefix is mapped to theassociation A card type by the same processes, and the transaction isprocessed as an association A card transaction. By assigning differentcard types to different merchants, the co-branded card product can bemade to have the desired behavior. More than two brands can be supportedif desired. Also, if retailer D desired to accept association A cardproducts other than the co-branded product, a card type that mapped toall of association A's prefixes other than the co-branded prefix(es) canbe defined and included in merchant card type list 400 for retailer D'soutlets.

It is to be understood that co-branding for any card product is not arequirement of the present invention. In general, co-branding would beimplemented only where there was an agreement in place between partiesdesiring such an arrangement. Once such an agreement is in place, cardtype controlled processing enables a third-party provider (or acquirer)to support such an arrangement.

Other embodiments of the present invention may support specialprocessing rules imposed on particular merchants. For example, a vendormay make an arrangement with a card-issuing bank to provide “statementstuffers,” i.e., special offers made available to that bank'scardholders. In such arrangements, it is generally expected that thevendor will accept only orders placed by the issuing bank's cardholdersusing the issuing bank's cards (not orders placed using other cards fromthe same association) and that such transactions will be settleddirectly with the issuing bank, without going through any cardassociation or interchange. In an embodiment of the present invention,this arrangement can be enforced. For instance, a special card type canbe defined to includes only prefixes assigned by the card association toa specific issuing bank and designating the issuing bank as the routingdestination. The vendor's merchant card type list can include only thisspecial card type. As a result, only the issuing bank's cards areaccepted by the vendor, and the transactions are processed in thedesired manner. It will be appreciated that a vendor could conductstatement stuffer operations concurrently with a number of card issuingbanks. A special card type could be defined for each such bank, and allsuch card types could be assigned to the vendor.

Yet other embodiments of the present invention may support additionaldistinctions among card products included in the same card type. Asdescribed above, card types are defined by master card product list 200and provide at least an association between a set of prefixes and arouting destination. In some instances, however, it may be useful todistinguish between card products that are processed in the same way.For instance, it may be desirable to distinguish association A's creditcard product from association A's debit card product, even though theacquirer routes all transactions for both card products to associationA's interchange. Such distinctions could be useful, e.g., to applydifferent discount rates if association A charges different interchangefees for credit card and debit card transactions, or for reportingpurposes.

In one embodiment of the present invention, such distinctions aresupported by providing one or more card product identifiers associatedwith each card type. For instance, a card product identifier may be athree-character alphanumeric code. Associated with each card productidentifier is an appropriate subset of the prefixes associated with thecard type. A merchant may elect to accept all card products within agiven card type or select individual card products to be accepted. Forinstance, a merchant may choose to accept credit cards but not debitcards from a particular association. In this case, prefixescorresponding to debit card products are removed from the merchant cardtype list for that merchant.

It should be noted that card products can also be distinguished bydefining each card product as a different card type; however, providingfor distinctions of card products within a card type may simplifyoperations by reducing the number of card types. In addition, a cardassociation that provides multiple card products may require merchantsto accept all of the association's card products or none of them.Grouping all card products of an association under a single card typemay assist operators of platform 100 in enforcing such a rule.

In some embodiments, card product identifiers could also be used toestablish a discount rate dependent on the card product. For instance,suppose that card association A issues both a debit card and a creditcard, and charges a higher interchange fee for debit card transactionsthan for credit card transactions. To reflect the difference in itscosts, an acquirer may desire to charge merchants a higher discount ratefor debit card transactions. By associating a discount rate with eachcard product, it would be possible to enable an acquirer to make thesedistinctions.

In another embodiment, card product identifiers may also be used togroup cards issued under different labels together. For instance, asingle issuer may issue private label cards for a number of retailers;transactions using all such retailers' cards are routed to the samedestination. To facilitate handling, the various retail card productsissued by this issuer can be assigned the same card type but differentcard product identifiers. As long as a merchant can select which cardsto accept at the card product level, this would not result in a merchantbeing required to accept a different retailer's card.

In yet another embodiment of the present invention, for each card type,debit card products and credit card products may be distinguished. Thiscan be done with or without distinguishing every card product. Merchantcard type list 400 may include an indicator for each card type to showwhether debit card products, credit card products, or both are to beaccepted. This is just one example of the ways in which the dataincluded in merchant card type list 400 may be varied.

While the invention has been described with respect to exemplaryembodiments, one skilled in the art will recognize that numerousmodifications are possible. For instance, in addition to purchase cards(e.g., credit cards and debit cards), other types of non-cash paymentinstruments (e.g., electronic checks) may be included. Further, anyformat for card type definitions and associated parameters may be usedas long as the card type definition includes information sufficient tocontrol transaction processing. Determining a card type for atransaction may be implemented in various ways using any informationobtainable from the presentation instrument.

Card types may be defined to include arbitrary combinations of cards. Asnoted above, each card product could have a different card typeidentifier, or cards issued under different labels could be groupedtogether as a single card type. In some cases a card type may includeonly some cards corresponding to a particular card product. Informationmay be stored and accessed at the merchant level or acquirer level asdesired.

The processes described herein are not limited to platform 100 and maybe implemented using any suitable components, including hardware,software, and any combination thereof. Embodiments of the presentinvention may also use any conventional processing steps and transactiondata formats.

Embodiments of the present invention are suitable for use by anacquiring bank (or any other entity that performs the acquirerfunctions) or a third-party provider.

Thus, although the invention has been described with respect toexemplary embodiments, it will be appreciated that the invention isintended to cover all modifications and equivalents within the scope ofthe following claims.

1-15. (canceled)
 16. A method of processing purchase card transactions,comprising: defining a plurality of card types, at least one of theplurality of card types corresponding to a purchase card and havingassociated therewith a plurality of merchant-specific sets oftransaction processing parameters; authorizing each of a plurality ofmerchants to accept one or more of the plurality of card types; and upona cardholder presenting to a merchant the purchase card corresponding tothe at least one card type having associated therewith the plurality ofmerchant-specific sets of transaction processing parameters for atransaction, processing the transaction using one of the plurality ofmerchant-specific sets of transaction processing parameters thatcorresponds to the merchant.
 17. The method of claim 16, wherein a firstone of the plurality of merchant-specific sets of transaction processingparameters includes a first routing destination parameter and a secondone of the merchant-specific sets of transaction processing parametersincludes a second routing destination parameter different from the firstrouting destination parameter.
 18. The method of claim 17, wherein: thepurchase card bears a first badge identifying a first card issuingentity and a second badge identifying a second card issuing entity; thefirst routing destination parameter corresponds to a routing destinationfor a card product of the first card issuing entity; and the secondrouting destination parameter corresponds to a routing destination for acard product of the second card issuing entity. 19-60. (canceled)